Method and system for interrupt handling using device pipelined packet transfers

ABSTRACT

A method and apparatus is provided in which Pipelined Packet Transfers (PPT) are implemented. The PPT methodology includes a request phase and a response phase. The PPT request phase involves a PPT request master delivering to a PPT request target a source address, a destination address and an information packet for the interrupt being requested. The PPT response phase involves the PPT request target becoming a PPT response master with the PPT response master delivering to a PPT request master a destination address and a data packet which includes the interrupt processing information. Pipelined Packet transfers (PPT) are ordered in accordance with a predetermined processing priority to improve performance and avoid deadlock.

RELATED APPLICATIONS

The present application is related to a co-pending application entitled“METHOD AND SYSTEM FOR INTERRUPT HANDLING USING SYSTEM PIPELINED READTRANSFERS”, application Ser. No. 09,224,119 filed on even date herewithnow U.S. Pat. No. 6,418,497 and “PIPELINED READ TRANSFERS”, applicationSer. No. 08/931,705 previously filed now U.S. Pat. No. 6,240,474 bothapplications assigned to the assignee of the present application.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to information processingsystems and more particularly to an improved information transfermethodology in a computer-related environment. Still more particularly,the present invention relates to a method and system for input/outputdevice read transfers that utilize a request phase and a response phasein association with the systems interrupt controller.

2. Description of the Related Art

As computer systems and networked computer systems proliferate, andbecome integrated into more and more information processing systemswhich are vital to businesses and industries, there is an increasingneed for faster information processing and increased data handlingcapacity. Even with the relatively rapid state-of-the-art advances inprocessor technology, and the resulting increased processor speeds, aneed still exists for faster processors and increased system speeds andmore efficient information processing methodologies. This need is atleast partially due to a growing number of computer applications andcapabilities, including extensive network and rich graphics and displayapplications among others. As new applications for computers areimplemented, new programs are developed and those programs are enrichedwith new capabilities almost on a daily basis. While such rapiddevelopment is highly desirable, there is a capability cost in terms ofsystem speed.

One of the problems that have been difficult to solve with the rapidgrowth of computer data or information-processing systems is thecomplexity of interrupts from I/O devices. There are a number ofproblems that need to be solved simultaneously relative to interrupts,more specifically, scalability, data coherency, latency and how toconnect far removed remote input/output devices. In terms ofscalability, the problem is in how to scale from a small number ofdevices to a large number without incurring larger than necessary costsat the low end or limiting the number of interrupting devices at thehigh end. The problem encountered in data coherency is how to assurethat the interrupt is not serviced by the system before the data is atits destination. In today's computer systems, the I/O device transfersthe data through host bridges and the like and signals that theoperation is complete through a separate path. If this separate path isfaster the path that the data takes, then the interrupt could beserviced before the data is at the destination, and wrong data could beaccessed.

The problem inherent in latency is how to reduce the service time andoverhead of a device interrupt. If the latency to access the I/O deviceto gather status or reset interrupts is large, then the interruptservice time is extended, affecting the amount of useful work that thesystem can perform. Lastly, with respect to remote input/output (I/O)devices, a problem exists is how to interconnect the interrupts from I/Odevices that may be located across cables or fiber optic links (a veryreal possibility because all the I/O in large systems may not fit insidea relatively small box). Running separate wires from each I/O device tosome centrally located interrupt controller may not be feasible.

In the past, there have been a number of attempts to solve some of theseproblems individually. Therefore, there is a need for an improvedinformation processing methodology and system in which information ismore efficiently transferred between master and target devices duringinformation processing transactions and which offers a global solutionto all the problems stated above. This invention solves these problemsin a novel and unique manner that has not been part of the artpreviously.

SUMMARY OF THE INVENTION

It is therefore one object of the present invention to provide a methodand system for scaling from a small number of devices to a large numberwithout incurring larger than necessary costs at the low end or limitingthe number of interrupting devices at the high end.

It is another object of the present invention to provide a method andsystem in which information is more efficiently transferred byincreasing data coherency and reducing latency between master and targetdevices during information processing transactions.

It is still yet another object of the present invention to provide amethod and system in which interrupts can be may be transferred from aremotely attached I/O device.

The foregoing objects are achieved as is now described. A method andapparatus is provided in which Pipelined Packet Transfers (PPT) areimplemented. The PPT methodology includes a request phase and a responsephase. The PPT request phase involves a PPT request master delivering toa PPT request target a source address, a destination address and aninformation packet for the interrupt being requested. The PPT responsephase involves the PPT request target becoming a PPT response masterwith the PPT response master delivering to a PPT request master adestination address and a data packet which includes the interruptprocessing information. Pipelined Packet transfers (PPT) are ordered inwith a predetermined processing priority to improve performance andavoid deadlock.

All objects, features, and advantages of the present invention willbecome apparent in the following detailed written description.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained when thefollowing detailed description of a preferred embodiment is consideredin conjunction with the following drawings, in which:

FIG. 1 is a block diagram of a typical computer related informationprocessing system in which an exemplary embodiment of the presentinvention may be implemented;

FIG. 2 is a block diagram of an exemplary pipelined read transfer (PPT)master-target configuration;

FIG. 3 is depicts a digital format for a PPT request in accordance withthe present invention;

FIG. 4 is depicts a digital format for a PPT request in accordance withthe present invention;

FIG. 5 is a flow chart illustrating a functional flow for a PPT requestmaster processing an interrupt;

FIG. 6 is a flow chart illustrating a functional flow for a PPT requesttarget processing interrupts received from a PPT request master; and

FIG. 7 is a flow chart illustrating a functional flow for a PPT responsemaster processing the end of an interrupt operation.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

With reference to FIG. 1, the various methods discussed herein may beimplemented within a typical computer system 101 that may include one ormore computers or workstations in various combinations. An exemplaryhardware configuration of a computer system which may be used inconjunction with the present invention is illustrated and includes aprocessor device 103, such as a conventional microprocessor, and anumber of other units interconnected through a system bus 105, which maybe any host system bus. The system bus may have one or more additionalprocessors connected to the bus such as processor 107. It is noted thatthe processing methodology disclosed herein will apply to many differentbus and/or network configurations. The bus 105, as well as any of theother busses illustrated, may be extended as shown to include furtherconnections to other computer systems, workstations or networks, andother peripherals and the like. The computer system shown in FIG. 1includes a local memory 109 and an interrupt controller 104 for use withone aspect of the present invention.

The system bus 105 is connected through a PCI (Peripheral ComponentInterconnect) Host Bridge A circuit 111 to a second bus 113, which, inturn, is connected through an expansion bus interface 115 to anexpansion bus 117 in the present example. The expansion bus 117 mayinclude connections to a keyboard/mouse adapter 119 and also to otherperipheral device adapters such as peripheral device adapter 121. Thesystem bus 105 may also be connected through additional bridge circuitssuch as PCI Host Bridge B 123, to a corresponding PCI bus 125 to whichadditional PCI devices 127 and 129 are connected.

In general, throughout this disclosure, the following conventions andterminology are used. The term “PPT” refers to a pipeline packettransfer. The term “PPT request master” is used to refer to a PCI busmaster or system bus master issuing a PPT request command. A “PPTrequest target” refers to a PCI bus target or system bus targetresponding to a PPT request command. A “PPT response master” refers to aPCI bus master or system bus master returning PPT response data and a“PPT response target” refers to a PCI bus target or system bus targetdevice accepting PPT response data. A PCI or system bus device is a PPTrequest master when it issues a PPT request. A PCI or system bus deviceis a PPT response target when data is returned by a PPT response master.A PPT request master device typically becomes the PPT response targetfor the PPT requests that it issues, but it is not required. The PPTresponse target could be a third device. A PCI device is a PPT requesttarget when it receives a PPT request and a PCI device becomes a PPTresponse master when it is able to return the PPT requested data.

A bridge that supports the PPT command will forward PPT requests and PPTresponses between its primary and secondary busses. For example a bridgethat receives a PPT request as a PPT request target on a primary buswill forward the PPT request on to the secondary bus by becoming a PPTrequest master on the second bus. Similarly, a bridge that receives aPPT response as a PPT response target on a primary bus will forward thePPT response onto the secondary bus by becoming a PPT response master onthe secondary bus.

FIG. 2, there is shown an exemplary implementation within which aPipeline Packet Transfer (hereinafter referred to as “PPT”) operationmay be accomplished. Generally, PPT capable devices will use a generaltwo-phase command, namely a request phase and a response phase,utilizing PPT master logic and PPT target logic. In accordance with thepresent invention, the request phase of the PPT command transmitsinterrupts from an I/O device 127 to the interrupt controller 104 andwill use the response phase to receive interrupt completion or rejectionstatus. Referring once again to FIG. 2, a PCI 127 device is shown havingdevice logic 205 which applies a PPT request signal through a PPTrequest master 207 onto the PCI bus 125 for delivery into the PCI hostbridge 123. The PCI host bridge 123 delivers the PPT request signal to aPPT request target 219 in the interrupt controller 104 via the systembus 105.

Referring now to FIG. 3, there is shown a PPT request 300 format that isissued by the PPT request master 207 when it wants access to a PPTrequest target 219. The PPT Request 300 contains three fields: a sourceaddress 302, a destination address 304, and an information packet 306.This format is a more generalized format than that used in applicant'spreviously filed application, “PIPELINED READ TRANSFERS”, AttorneyDocket AT9-97-261. The Source Address 302 (PPT-SA) is a 4 byte PCIaddress which the PPT request target 219 uses to determine where in theinterrupt controller 104 to write the interrupt. This address would besetup by the system configuration time into each I/O device'sconfiguration registers. The destination address (PPT-DA) 304 is a 4byte PCI address which the PPT request 219 uses when returning theinterrupt status. The I/O device 127 sets this to an address where theinterrupt response should be placed. The IRQ service/source 308 in thePPT information packet 306, is defined as a 16-bit field, whichspecifies to the interrupt service routine which device driver to callto service the interrupt and to the device to indicate what is thesource of the interrupt in the I/O device. The number of bits used forIRQ server and the number for IRQ source is operating system dependent.

Referring once again to both FIGS. 2 and 3, the priority field 310 isthe priority of the interrupt. This is used by the interrupt controller104 to determine whether or not to queue the interrupt or to return itto the I/O device 127. The priority would be setup by the systemconfiguration code at configuration time into each I/O device'sconfiguration registers, or would be setup by the operating system. Thetype field 312 determines the PPT packet type. The field is defined as a3-bit field. As shown in FIG. 2, the PPT request target 219 inputs thePPT request 300 to one of a plurality of PPT response master “n”circuits 221. The PPT response master circuits 221 are arranged to applyrequest information to the interrupt control logic 223. If the interruptcontrol logic 223 accepts the request, the request 300 is forwarded tothe appropriate CPU for action as shown in FIG. 2. The interruptcontroller 104 then receives the appropriate response from the CPU tothe PPT response master 221 for delivery to the PCI device 127 via thesystem bus 105. A group of PPT data buffers 227 are also arranged toreceive PPT response data from the interrupt control logic 223 andprovide an input to the PCI device 127 via system bus 105, PCI hostbridge 123 and PCI bus 125.

Referring once again to both FIGS. 3 and 4, the format for the PPTresponse packet 314 is as follows: the value of the destination addressfield 320 is the same as for the same field in the PPT master request322. For PPT packets of type 0b001, there will only be 4 bytes of data.The data fields are defined as follows: the IRQ server/source 324 is thesame as delivered to the interrupt controller 104. This maybe used bythe I/O device 127 to match up the status with the source of theinterrupt (devices with one or few interrupts may not need to do this,or may optionally use the destination address to define the source. Thestatus field 328 is defined as follows: 0b00001 is interrupt accepted,0b00010 is interrupt rejected, and 0b00100 is interrupt servicingcomplete. Note that the I/O device 127 needs to be prepared to receivean interrupt rejection following an interrupt accept, up until the timewhen the interrupt complete is received. That is so the interruptcontroller 104 can bump an interrupt from its queue if it needs room fora higher priority interrupt (this is the key to the scalability of thisstructures).

Referring once again to FIG. 4, the delay field 326 is used to give ahint to the I/O device 127 as to how long it should wait between gettingan interrupt rejection and the representation of that interrupt. Thevalue is in microseconds, with 0b0000 meaning that the I/O device 127needs immediate servicing, it may ignore the delay field for thatoccurrence of that interrupt. As an alternate implementation to thedelay-and-represent implementation, the system may be implemented toallow the interrupt controller to broadcast a “represent any interruptsnow” command on the buses. In the PCT environment, that would need to bepresented as a PCI Special Cycle command. Note that those skilled in theart will recognize that the bit fields defined above could be definedwith different size or locations and still have significantly the sameinvention.

The PPT request packet is distinguished from prior art Pipeline ResponseTarget PRT (described in applicants previously filed application“Pipelined Read Transfers”) by the type field 312. For the PRT, thisfield was designated as “Reserved” and therefore as is common in thestate of the art, would have a value of 0b000. For the PPT command, thetype field would be non-zero and for the PPT used for transferringinterrupts, the type field would be 0b001. The PPT request target willuse the destination address received in the PPT request packet as theinitial destination address in the PPT response packet.

Turning back to FIG. 2, the PPT response 221 and associated PPT data 227is inputted to the PCI host bridge 105 and delivered the PCI device 127through PCI bus 125. It should be understood for purposes of the presentinvention, that the PCI host bridge 123 can either be configured totransfer back and forth the PPT package format described above for bothrequest master signals and response master signals or the interruptcontroller 104 can be implemented as part of the PCI host bridge 123.The PCI device 127 receives the PPT response 316 data in its PPTresponse target 211 and associated PPT response data 318 in its PPT databuffers 215 for input into PCI device's 127 device logic 205 forprocessing. FIGS. 5, 6 and 7 detail the operation of performing readtransfers in accordance with the present invention as described below.

Referring now to FIG. 5, there is shown a flow chart illustrating afunction flow for a PPT request master 207 requesting an interrupt.Staring at 701, the PCI device 127 prepares an initial PPT request 300by formatting a PPT source address 302, PPT response destination 304,IRQ server/source number 308 and priority 310, shown in step 703. Next,shown in step 705 the PPT request 300 is then sent to the interruptcontroller 104, as described above, and a system timeout timer isstarted. The process proceeds to step 707 wherein the PCI device 127checks to see if the interrupt controller returned a PPT response 314,if not the timer is checked for any timeouts, shown in step 709. If notimeouts have occur, the loop continues with the PCI polling for areturned response at step 707. However, if a timeout occurs theinterrupt controller is too busy to service the interrupt, as will bemore full described below, and the process starts all over again at step703.

Referring once again to FIG. 5, if the response 314 received by the PCIdevice 127 is that the interrupt has been rejected, the device logic 205decides if the service requested is urgent, shown in steps 711 and 713.If the service is not needed urgently, the PCI device waits a suggestedtime delay as indicated by the delay field 326 of the response data 318,step 715 and then starts over at step 703. However, if the service isurgently needed the device logic 205 immediately starts over andreissues the request 300. If the interrupt is not rejected then theprocess as shown in step 717 checks see if the interrupt controller 104has accepted the request 300. If the interrupt is accepted, the processperforms steps 719 and 721 wherein a response timer is started and thePCI device polls the timer for a response timeout. Before a responsetimeout has occurred, the PCI device waits to receive the PPT responseto take the appropriate completion of reading the data, as shown in theloop of steps 721 and 723. If a PPT response is received the processloops back to step 711. If a timeout does occur before a response isdelivered from the interrupt controller, the process as shown in step725, logs an error in the device and sets up and error interrupt andreturns to the start of the process 703.

Referring again to FIG. 5, if the interrupt response is not accepted instep 717, the process goes to step 727 to check if the status interrupthas been completed. If not an error is reported to the system as shownin step 735. If however, the status interrupt is completed, a pendinginterrupt bit is cleared for the specified interrupt and the PCI pollsfor any other interrupts pending, as shown in steps 729 and 731. If nointerrupts are pending the system goes idle, as shown in step 733 or thePCI checks to see if another PPT response 314 has been returned at step707.

Referring now to FIG. 6, there is depicted a flowchart illustrating afunctional flow for a PPT request target 219 and interrupt controller223 processing interrupts from a PPT request master 207. As shown insteps 801 and 803, the interrupt controller receives the interruptrequest packet 300 from the PPT request master 207, as described above.The process then goes to step 805 wherein the interrupt control logic223 checks to see if any interrupts are pending. If no interrupts arepending, the response master 221 sends to the PCI response target 211that the status has been accepted, as shown in step 809. The interruptcontroller 104 through its interrupt control logic next determines ifthe accepted priority has a greater processing priority for acceptanceof processing to the appropriate CPU. If not, the process loops untilthe appropriate priority level is reached as shown in step 813. When thepriority is appropriate, the request is sent to the CPU and theinterrupt presentation process is complete.

Referring once again to FIG. 6, if there are interrupts pending at step805, the interrupt controller 104 determines if the newly receivedinterrupt is a higher priority at step 807. If the interrupt does nothave high enough priority the response master 221 sends a PPT response314 to the PCI device 127 that the interrupt has been rejected and theprocess completes, as shown in steps 819 and 821. If however in step807, there is no higher interrupt priority, the process proceeds to step811 wherein older interrupts are rejected and the new interrupted isaccepted, shown in steps 811 and 815. This accomplished by theappropriate PPT response signal 314 being sent to the PPT responsetarget 211. The process then continues at step 813 as described above.

Referring now to FIG. 7, there is depicted a flowchart illustrating afunctional flow for a PPT response master 221 processing the end of aninterrupt operation. As shown in steps 823 and 825, the interruptcontrol logic 223, continuously checks to see if the end of theinterrupt process has been signaled by the software. When the responsemaster 221, receives the software. When the response master 221,receives the appropriate signal, it sends a PPT response 314 indicatingto the PCI device 127 that the requested servicing has been completed,as shown in steps 829 and 827.

The protocol developed by this invention allows the local interruptcontroller 104 to bounce back interrupts to the I/O devices if itsqueues are full. This overcome the prior art methods of scalability.There is no per-interrupt resources necessary in the local interruptcontroller 104, and therefore the resources in the local interruptcontroller 104 piece do not need to grow linearly with the number of I/Odevices that is to be supported. Additionally, in terms of datacoherency, it can be appreciated that the above-described PPT packetsthat contain the interrupt information will not bypass the data that iswritten by the I/O device 127, and since the I/O device 127 originatesboth, with proper system design, the data will reach its destinationwithout software having to execute a load to flush the data to itsdestination, giving better system performance.

Since the interrupt completions can originate from the local interruptcontroller 104 and go all the way back to the I/O device, 127 theinterrupt service code does not need to write to the device 127 tosignal interrupt completion. Likewise, on interrupt generation, the I/Odevice 127 sends the information needed by the device driver todetermine the reason for the device's interrupt to the controller andtherefore the latency of polling the I/O device on interrupt iseliminated. Lastly, all transaction go across the same path as data, andtherefore the mechanisms used to extend the I/O out away from the box,will also work for the interrupt controller.

The method and system of the present invention has been described inconnection with a preferred embodiment as disclosed herein. Although anembodiment of the present invention has been shown and described indetail herein, along with certain variants thereof, many other variedembodiments that incorporate the teachings of the invention may beeasily constructed by those skilled in the art. Accordingly, the presentinvention is not intended to be limited to the specific form set forthherein, but on the contrary, it is intended to cover such alternatives,modifications, and equivalents, as can be reasonably included within thespirit and scope of the invention.

What is claimed is:
 1. A method for transferring a pipelined packettransfer (PPT) from an input/output device, said method comprising:sending a PPT request packet having a source address, responsedestination and information packet from an input/output device to aninterrupt controller across a databus located between said input/outputdevice and said interrupt controller; receiving a PPT response packetfrom said interrupt controller across said databus; and resending saidPPT request packet across said databus from said input/output device ifa PPT reject response packet is received from said interrupt controllerbefore a PPT complete response packet.
 2. A method according to claim 1,further comprising: receiving a PPT accept response packet prior toreceiving said PPT complete response packet.
 3. A method according toclaim 1, said PPT reject response packet further comprising a valuerepresenting a suggested length of time for said input/output device towait before resending said PPT request packet after receiving said PPTreject response packet.
 4. A method according to claim 1, wherein saidsource address locates said interrupt controller, said responsedestination locates said input/output device and said information packetspecifies a device driver to call to service an interrupt requested bysaid PPT request packet.
 5. A method according to claim 1, wherein saidinput/output device and said interrupt controller communicate said PPTrequest packet and said PPT response packet without an intermediaryprocessing.
 6. A method according to claim 1, further comprising: saidPPT complete response packet clearing an interrupt bit in saidinput/output device for a specified interrupt.
 7. A method according toclaim 1, further comprising: starting a response timer for initiating aresponse timeout upon receiving said accept status wherein saidinput/output device sets up an error interrupt if said PPT completeresponse packet is not received before said response timeout.
 8. Amethod according to claim 1, further comprising: transmitting said PPTrequest packet to a remotely located interrupt controller on a network.9. A method according to claim 3 further comprising: waiting saidsuggested length of time before resending said PPT request packet fromsaid input/output device after receiving said PPT reject responsepacket.
 10. An information processing system comprising: means forsending a PPT request packet having a source address, responsedestination and information packet from an input/output device to aninterrupt controller across a databus located between said input/outputdevice and said interrupt controller; means for receiving a PPT responsepacket from said interrupt controller across said databus; and means forresending said PPT request packet across said databus from saidinput/output device if a PPT reject response packet is received fromsaid interrupt controller before a PPT complete response packet.
 11. Aninformation processing system according to claim 10, further comprising:means for receiving a PPT accept response packet prior to receiving saidPPT complete response packet.
 12. An information processing systemaccording to claim 10, wherein said PPT reject response packet furthercomprises a value representing a suggested length of time for saidinput/output device to wait before resending said PPT request packetafter receiving said PPT reject response packet.
 13. An informationprocessing system according to claim 10, wherein said source addresslocates said interrupt controller, said response destination locatessaid input/output device and said information packet specifies a devicedriver to call to service an interrupt requested by said PPT requestpacket.
 14. An information processing system according to claim 1,wherein said input/output device and said interrupt controllercommunicate said PPT request packet and said PPT response packet withoutan intermediary processing.
 15. An information processing systemaccording to claim 10, further comprising: means for said PPT completeresponse packet clearing an interrupt bit in said input/output devicefor a specified interrupt.
 16. An information processing systemaccording to claim 10, further comprising: means for starting a responsetimer for initiating a response timeout upon receiving said acceptstatus wherein said input/output device sets up an error interrupt ifsaid PPT complete response packet is not received before said responsetimeout.
 17. An information processing system according to claim 10,further comprising: means for transmitting said PPT request packet to aremotely located interrupt controller on a network.
 18. An informationprocessing system according to claim 12, further comprising: means forresending said PPT from said input/output device after waiting saidsuggested length of time.
 19. The method of claim 1, wherein said PPTreject response packet is received after said PPT accept response packetdue to a higher priority interrupt packet displacing said PPT requestpacket from a queue in said interrupt controller.
 20. The informationprocessing system according to claim 11, wherein said PPT rejectresponse packet is received after said PPT accept response packet due toa higher priority interrupt packet displacing said PPT request packetfrom a queue in said interrupt controller.